Subject: APPN Data Link Control Architecture

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 19 Dec 1994 16:01:00 -0500

I believe that there is an erroneous assumption at the heart of the design
of the APPN configuration model and in the relationship of Configuration
Services to Data Link Control.  This incorrect assumption has led to a
questionable design from which the concerns about APPN DLC support which are
the focus of the public datanet SIGlet arise.

The mistaken assumption is that APPN is the master of the networking universe.
This design assumption obviously arose out of the S/36 origins of APPN,
because APPN was essentially the only protocol supported by the S/36.  This
was a natural consequence of the view of APPN as the evolutionary successor
to SNA, which, as we learned at the AIW, was intended by IBM to be the Single
Network Architecture.

As a result of this assumption APPN provides within its NOF and CS-DLC
interfaces the requirement that the characteristics of the media interfaces
are defined by APPN.  In a multi-protocol router, or even a SNA device (such
as the 3174) to which some additional protocols such as IP and bridging have
been added, this is a questionable requirement.  It is only supportable as
long as APPN/SNA is the overwhelmingly dominant protocol on the module.
That, clearly, is no longer true in most of our implementations.

Consider DEFINE_PORT on the NOF interface.  According to the architecture it
carries, among other pieces of information:

 - maximum received BTU 
 - link role
 - transmit/receive capability
 - local MAC/SAP

There are several problems with these attributes:

 1) They don't really have anything to do with the APPN protocol. Nothing
    happens differently in the APPN layer 3 and above based upon these
    attributes.
 2) They are characteristics of the underlying data link control layer.
    Indeed in some cases they are characteristics of the hardware and
    therefore not amenable to software configuration.
 3) If a physical interface is shared with other, non-APPN, protocol stacks,
    how do you resolve conflicts between APPN's values of these attributes,
    and those of other routers?
 4) They create definitions which are assymetrical from the point of view of
    the network administrator.  For example link role and transmit/receive
    capability are irrelevant parameters on a LAN interface, while local
    MAC/SAP is irrelevant on an SDLC port.

I therefore contend that the APPN architecture should remove all such
parameters from the NOF and from the flows from CS to DLC.  Instead if it
is actually required that APPN have this information, the information should
be learned from the DLC.  That is the definition of link characteristics
should be assumed to be an unarchitected function of the DLC implementation.
To the extent that APPN needs this information it should be communicated from
the DLC implementation to CS.

Once you assume that DLC provides information to CS on the characteristics of
the interface, then it is clear that many other attributes should also
logically flow in that direction.  For example CS and TRS have
functionality which is dependent upon whether a Port is switched, leased, or
SATF.  However that is information which the physical interface knows, and
hardly needs to be told by APPN.

I was led to this conclusion by considering sharing a Port, for example a TRN
LAN or even an individual DLCI on a Frame-Relay interface, between IP and
SNA.  I noticed that, unlike APPN, IP had no media dependent configuration
information.  IP does not even know the MAC addresses of devices to which it
is attached across a LAN until it learns them through a level 3 address
resolution protocol.  APPN suffers much by comparison in terms of the amount
of information which it demands be pre-subscribed.  

I therefore propose that all media dependent information, or information
which can be logically learned from the media interface, be removed from the
APPN configuration model and assumed to be provided by the DLC or learned
through exchanges on the CP-CP session.

In more detail, I propose the following architectural changes to the CS-DLC
interface.  Note that these changes imply changes to the NOF interface:

create(DLC_CREATE_PARMS)
------------------------
The following parameters are removed from the create(DLC_CREATE_PARMS) and
are provided to CS by the response to the creation of the DLC:

 - link station operational mode (NRM/ABM)
 - remote IPL/IML capabilities

There is no DLC instance which supports both NRM and ABM.  The ability to
support IPL is only defined for the SDLC leased protocol, and whether it is
supported by a specific Port is clearly a Port level characteristic, not a
characteristic of the entire DLC.

ACTIVATE_PORT
-------------
The following parameters are removed from the ACTIVATE_PORT request and
are provided to CS by the response:

 - maximum receive BTU size
 - link role
 - transmit/receive capability
 - local MAC/SAP

CONNECT_OUT
-----------
The following parameter is removed from the CONNECT_OUT request:

 - media address (phone number, link address, MAC/SAP) except if this is
   the result of an ACTIVATE_ROUTE request from SS in which case it is
   presented in the format in which it is stored in the TDB.

In place of the media address some sort of implementation defined connector
is required to associate the link station to the address resolution
mechanism.  Note that in this proposal CS is NEVER told what the media
address is.  The only process which knows media addresses is TRS, and TRS
learns them from flows on the CP-CP session.  This makes the introduction of
a discovery, or address resolution protocol architecturally easy, since the
APPN node itself is out of the circuit.  However to have the DLC implement
discovery or address resolution requires that the requested destination CP
address (or XID value for LEN nodes) be provided on the CONNECT_OUT.

CONNECT_IN
----------
The following parameter is removed from the CONNECT_IN request:

 - media address (phone number, link address, MAC/SAP) 

In this proposal CS is not told what the media address is.  All CONNECT_IN
requests are treated like switched call in requests, and the association
between the calling link station and a possible existing definition is made
using the XID or CPNAME values.  TRS learns the media address of the
connection station through CP-CP flows.

Comments?

Merry Christmas, Joyeux Noel, Feliz Navidad, Buona Natale, Frohliche
Weihnachten, S Rodestvom Christovom, Kala Christooyenna.